14 мая 2024
Рассмотрим несколько типичных сценариев использования ИИ в задачах классического документооборота.
Опыт миграции БД в рамках СЭД на PostgreSQL
- Тигран Петросян
- 21 марта 2024
- Статьи
Миграция базы данных обеспечивает компании импортонезависимость и снижает лицензионные затраты. При этом стоимость перехода на новую СУБД зависит от 3 составляющих:
1. Сколько кода обрабатывается на стороне БД.
2. Сколько данных хранится в БД, какой объём требуется мигрировать и в какой срок.
3. Насколько отличается язык программирования исходной и новой БД.
В этой статье мы поделимся опытом миграции БД в рамках СЭД на базе платформы Docsvision с использованием утилиты миграции.
Принцип миграции
Мы исходим из принципа, что любые изменения, которые мы планируем внести в промышленную среду, вначале должны быть опробованы на тестовом сервере. Значит, процесс миграции мы начинаем с подготовки тестовой среды. Исторически промышленная база данных была выстроена на MS SQL и будет перенесена на PostgreSQL.
Тестовая среда содержала клон промышленного сервера приложений и сервера БД MS SQL на ОС Windows. Дополнительно мы развернули сервер БД PostgreSQL на Alt Linux.
Когда мы подготовили тестовую среду, распланируем этапы миграции БД:
- Подготовка исходной БД MS SQL
- Перенос большинства файлов в файловое хранилище
- Выгрузка исходной БД в csv файлы (утилита миграции)
- Конвертация выгруженных csv файлов (утилита миграции)
- Подготовка PG БД для миграции
- Миграция csv файлов в PG БД (утилита миграции)
Рассмотрим каждый из этапов.
Подготовка исходной БД MS SQL
Чтобы ускорить процесс миграции, требуется максимально уменьшить размер базы данных. Фактически для этого мы проводим генеральную уборку в системе, вычищаем неактуальные данные – в первую очередь, завершённые бизнес-процессы. Стоит очистить таблицы журналов, оставив только application-лог, удалить объекты из корзины.
Переносим все файлы, кроме системных и справочников, на файловое хранилище. В описанном кейсе мы создали новое файловое хранилище, группу для данного хранилища и правило, которое по приоритету было ниже, чем правила для системных файлов и справочников. С помощью скрипта мы добавили все существующие в базе файлы в очередь и дождались, пока файловый сервис обработает всю очередь. По итогу: за 12 часов файловый сервис перенёс около 400 000 файлов объёмом 100 ГБ.
Изначальный размер базы данных — 170 ГБ. После удаления устаревших данных и переноса бинарных данных из БД в файловое хранилище размер БД был равен 8 ГБ. Эти цифры наглядно показывают важность подготовки исходной базы данных для миграции.
Утилита миграции
В описанном кейсе для переноса БД с MS SQL на PostgreSQL мы использовали утилиту миграции, разработанную в «ДоксВижн». Утилита миграции – это консольное приложение. На вход она принимает ключи, которые мы опишем в продолжении статьи. Названия ключей интуитивно понятны:
- /help используется для получения информации по поддерживаемым ключам и их назначению;
- /ms и /pg нужны для указания строки подключения к соответствующему типу базы данных
- /test используется для проверки подключения;
- /p позволяет указать путь к папке, в которую будет выполняться экспорт либо производиться импорт.
Сначала с помощью утилиты мы создаём в базе данных вспомогательные объекты, а затем выгружаем данные из таблиц в csv файлы.
- /install используется для установки вспомогательных объектов в связке с ключом /ms, который указывает строки подключения к исходной базе данных. Такая команда формирует в базе данных служебные таблицы с информацией о ходе работы утилиты.
CloneDbUtil.exe /ms:"Initial Catalog=source_db; Data Source=server; Integrated Security = SSPI;" /install
- /export соответственно указывает на необходимость экспорта данных, после ключа /p мы указываем папку для экспорта csv-файлов. Ключ /l фиксирует ограничение на количество обрабатываемых таблиц. Таким образом выглядит команда для экспорта данных из таблицы исходной базы в csv-файлы.
CloneDbUtil.exe /ms:"Initial Catalog=source_db; Data Source=server; Integrated Security = SSPI;" /p:"D:\clone_db_data" /export /l:10
Обращаем внимание, что утилита миграции экспортирует данные только из таблиц, названия которых соответствуют маскам dvsys*, dvrep*, dvtable*.
После выгрузки данные из таблицы в csv-файлы требуют перекодировки, так как MS SQL отдаёт данные в формате Unicode, а PostgreSQL принимает в UTF8. Дополнительно требуется нормализовать некоторые символы, чтобы в дальнейшем корректно работала БД на PostgreSQL.
- /f запускает перекодировку, а ключи /infolder и /outfolder указывают папку с исходными csv-файлами и папку для перекодированных файлов. Если вместо папок требуется указать конкретные файлы, то используются ключи /in и /out.
CloneDbUtil.exe /f /infolder:"C:\clone_db_data" /outfolder:"C:\clone_db_data2"
На этапе перекодировки данных происходит удвоение файлов – а значит, требуется иметь достаточное дисковое пространство на машине, где выполняются операции.
Когда мы подготовили данные для новой БД, требуется создать её структуру в PostgreSQL, предварительно создав пустую базу данных.
- /clone берёт из источника БД метаданные и генерирует скрипты библиотек и карточек, по которым создаёт таблицы необходимой структуры в PostgreSQL.
CloneDbUtil.exe /ms:"Initial Catalog=source_db; Data Source=server; Integrated Security = SSPI;" /pg:"Server=127.0.0.1; Port=5432; Database=target_db; User ID=postgres; Password=password;" /clone
- /import – ключ для импорта файлов используется вместе с ключами /p, который указывает папку, где находятся сконвертированные csv-файлы, /ms и /pg – указывают строки подключения к базам данных источника и приёмника. Если использовать ключ /l, то можно установить ограничение на число обрабатываемых таблиц в команде.
CloneDbUtil.exe /ms:"Initial Catalog=source_db; Data Source=server; Integrated Security = SSPI;" /pg:"Server=127.0.0.1; Port=5432; Database=target_db; User ID=postgres; Password=password;" /import /p:"/home/pgadmin/migration" /l:25
Действия после миграции данных
Несмотря на то, что в базе данных PostgreSQL уже заполнены данными все таблицы из нашего источника, мы не можем сразу подключить её к консоли настройки. Чтобы подготовить новую базу для работы внутри системы на базе платформы Docsvision, мы должны сформировать хранимые процедуры и джобы.
- Выполнить полное обновление базы PG через консоль настройки Docsvision с понижением версий библиотек
- Загрузить заново все серверные расширения
- Сделать базу PG основной, отключить базу MS SQL
- Запустить все остановленные сервисы
- Проверить основные сценарии работы
Практический кейс миграции СУБД в рамках проектах СЭД
Николай Авдюшкин, генеральный директор «Эркер», поделился опытом реализации проекта по переходу на импортонезависимый стек, в том числе с применением утилиты миграции.
Организация работает в СЭД на платформе Docsvision с 2009 года, при этом часть решения функционирует на устаревшей версии продукта Docsvision 4.5, часть на актуальной версии платформы с доступом к системе через web-клиент. Решение развёрнуто на Windows Server и MS SQL Server. Объём БД без файлов ~200 Гб, объём вытесненных файлов ~ 1,5 Тб.
Заказчик поставил задачу полностью перенести актуальную часть решения на базе Docsvision 5.5 в импортонезависимую среду на серверное ПО – ОС Astra Linux и СУБД – PostgreSQL. Дополнительно требовалось перенести вытесненные файлы на новое хранилище на Linux. И самое важное – сроки были жёстко регламентированы, и нельзя было допустить простоя системы в рабочее время.
Миграция была реализована в 2 этапа. После подготовки к миграции команда проекта выполнила тестовую миграцию, которая выявила узкие места в процессе. В результате было проведено 3 пробных миграции в тестовой среде, определён тайминг всех шагов, разработаны методики испытаний решения после миграции.
Последовательность тестовой миграции
1. Миграция/конвертация БД с использованием утилиты миграции от вендора. Из опыта «Эркер», для конвертации нужно места ~ в 3–4 раза больше исходной БД, желательно SSD.
2. Решение конфликтов при конвертации и проверка работы представлений.
3. Проверка работы веб-расширений и серверных расширений, адаптация для работы на .Net 6.
Миграция основной среды
1. Отключение продуктивного сервера перед выходными, в пятницу вечером. Миграция БД на PostgreSQL и сервера на Astra Linux.
2. Проверка работы решения по разработанным методикам.
3. Загрузка файлов с файлового сервера Windows Server в БД PostreSQL.
4. Настройка вытеснения файлов из БД PostreSQL на файловую систему Astra Linux.
5. В понедельник пользователи начали работу в Docsvision через Web-клиент.
Что изменилось в работе пользователей:
- Изменился интерфейс предпросмотра файлов через Р7-Офис
- Появилось улучшенное меню создания новых документов
Вывод
Миграция на СУБД PostgreSQL — первый шаг на пути импортозамещения. И такой проект требует системного подхода и сильной команды с высокой компетенцией как в исходном продуктовом стеке, так и в новом. В процессе миграции важно сохранить целостность данных, следовать поставленным целям в рамках проработанного плана. Команда «ДоксВижн» готова поддержать такие проекты миграции.